NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/2595

Internet Message Format | 1996-08-06 | 3.6 KB

Path: locutus.rchland.ibm.com!usenet
From: [e-mail]
Newsgroups: comp.lang.c++
Subject: Re: Q:order of evaluation
Date: 18 Jan 1996 15:27:24 GMT
Organization: IBM OS/2 Device Driver Development  Rochester, MN
Message-ID: <4dloss$[e-mail]>
References: <4dfhlu$a33$[e-mail]> <4di5qb$qda$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: warpone.rchland.ibm.com
X-Newsreader: IBM NewsReader/2 v1.2

In <4di5qb$qda$[e-mail]>, Holger Maier <[e-mail]> writes:
>Please note that in
>  int i=1;int j=i+(i+=1);
>the value of i is modified only once. The ARM states that an
>expression where a value is modified more than once is undefined
>(ie: i = i++; ). But since i is not modified multiply and assignment
>returns the assigned value, this expression should be reasonable.
>Any comments??

No, no, no, no, NO!  Sheesh, won't these kind of constructs ever die?

From the ARM, chapter 5, "Expressions" pg. 46

  The order of evaluation of subexpressions is determined by the
  expression grammar.  The usual mathematical rules for associativity
  and commutativity of operators may be applied only where the operators
  really are associative and commutative.  Except where noted, the order
  of evaluation of operands of individual operators is undefined.

The key phrase here is "...order of evaluation of operands ... is
undefined."

That means that in the expression:

j = i + ( i += 1 );

The operands of operator + are i and a subexpression.  The compiler is
free to "evaluate" either operand first, then the other.  The compiler
can do it either way.  It could do it one way on one compile, and the
other on another compile just because some optimization or debug flags
changed.

The subexpression ( i += 1 ) has side effects on i.  However, _exactly_
when those side effects "take effect" on i is not defined.  It only has
to happen before the next sequence point.  The only sequence point in
this statement is the end of evaluation of the full expression. (ref 1-8
of the DWP)

The side effect could take place immediately on evaluation.  If so, then
i would be changed as soon as the ( i += 1 ) operand for operator + was
evaluated.  So, the LHS i could then evaluate to either 1 or 2,
depending on the (undefined) order of evaluation of the operands to
operator +.

Therefore, between sequence points this statement has side effects on i,
and two subexpressions referencing i.  This is not good.  In chapter 5,
para 4 of the DWP it states:

  Between the previous and next sequence point a scalar object shall
  have its stored value modified at most once by the evaluation of an
  expression.  Furthermore, the prior value shall be accessed only to
  determine the value to be stored.  The requirements of this paragraph
  shall be met for each allowable ordering of the subexpressions of a
  full expression; otherwise the behavior is undefined.

This statement violates the "furthermore" part of the paragraph.  The
scalar i is accessed twice, once to get the value to be stored (from the
+= operator) and again to evaluate the LHS operand for operator +.  This
makes the result of executing this statement undefined.

Some day I'll write a compiler that upon seeing this generates code to:

  1) Send an email note of appology to Bjarne Stroustrup for abusing
     his language.

  2) Reformat all disks connected to the machine.

Well, maybe not #1, he'd be inundated with email ;-)

Remember, short compact code is neat and fun etc. but don't pack too
much into one statement.


Phil Staite, team OS/2
internet: [e-mail]  internal: pstaite@rchland